To enhance system performance, it is helpful to know which modules within a system are most frequently executed. These most frequently executed modules are referred to as "hot" modules. Within these hot modules, it is also useful to know which lines of code are the most frequently executed. When there is a point in the code where one of two or more branches may be taken, it is useful to know which branch is the mainline path, or the branch most frequently taken, and which branch or branches are the exception branches.
A programmer hoping to improve system performance should focus his or her efforts on improving the performance of the hot modules and the most frequently executed lines of code within the hot modules. Improving the performance of the most frequently executed modules and code segments will have the most effect on improving overall system performance. It does not make sense to spend much time improving the performance of modules and code segments which are rarely executed, as this will have little, if any, effect on the overall system performance.
A programmer hoping to improve the performance of a module will group the instructions in the mainline branches of the module closely together. Keeping the mainline code packed closely together increases the likelihood of cache hits, since the mainline code is the code that will most likely be loaded into the instruction cache.
Performance tools are used to examine program code to determine the most frequently executed modules and instructions in a system. Performance tools may be implemented in hardware or software. Hardware performance tools are usually built into the system. Software performance tools may be built into the system or added at a later point in time. Performance tools implemented in software are especially useful in systems, such as personal computer systems, that do not contain many, if any, built-in hardware performance tools.
Some prior art software performance tools use an interrupt-driven method to monitor performance. Typically, the system is interrupted at set time intervals. At each interrupt, the performance tool samples the code that is running and adds data into a log.
There are several problems with this prior art approach. Because the code is sampled once per interrupt, the programmer never sees any data pertaining to code that is "disabled for interrupts" (i.e. code where interrupts are masked). The interrupt that stops the system and allows the performance monitoring to take place can never occur during code that is disabled for interrupts.
Another problem with this prior art approach is that the storage area quickly fills with data. This means the performance tool can only be run for a very short period of time, or the tool must stop the system to unload the data into another space, such as to disk. Stopping the system is very intrusive, as this type of stop would not occur during normal operations. Thus, stopping the system to unload performance data actually affects the system performance of the system that is being monitored.
Furthermore, sampling once per interrupt gives a ragged view of the performance data. It is difficult to accurately understand what is happening in the system because the performance data is collected at random points. There is no data collected pertaining to a sequence of instructions running in the consecutive order in which they were intended to execute.
Another type of prior art software performance tool keeps track of sequences of instructions by logging every instruction as it executes. However, there are several problems associated with this type of prior art approach. First, the storage area fills with data even more quickly than with the interrupt-driven performance tool. Therefore, this type of tool can only be run for very short periods of time, or the data must be unloaded to another storage area so often that the tool becomes prohibitively intrusive. Another problem with this type of tracing tool is that it typically requires changes, or "hooks," in the operating system code. There are often situations where a developer wishes to trace the instructions executing in an information handling system, but does not have access to the operating system code.
Consequently, it would be desirable to have a tracing tool that would accurately depict the instruction flow of code executing in an information handling system without requiring any changes to be made to the operating system code. It would also be desirable to have a tracing tool that did not require a large memory area in which to store data.